Review of KLA/Express
by
Shawn M. Gordon
President
The Kompany
Introduction
KLA/Express is one of those products that you never saw advertise (until recently), but if you knew what it was you couldn’t live without it. I became familiar with it several years ago at a spectrum site that I was working at before KLA had been bought by UNISON, and it helped boost our performance radically. Now I suppose I should tell you what KLA/Express is, and what it does.
Perhaps you are familiar with the dispatcher on MPE, it’s that TUNE command that you hardly ever use to specify the filter and/or priority limits of the circular subqueues CS, DS, ES. The only control HP ever gave you over these was being able to define the start and end points of each queues priority and the minimum and maximum filters, which the CPU uses to determine if a process should be decreased in priority, for each of the queues.
I know it took me some time to understand how the TUNE command worked and even more time to determine what where the best values for my system, because you can REALLY foul up your response time by setting these badly. The beauty of KLA is that it allows you to allocate these queue resources exactly how you want to, down to a process or user level, thus giving you the ability to really fine tune your response time. There are other features as well in the software which I will also cover.
Let me give you a little background on my system first, we are running an HP 3000 series 70 with 12 meg of main memory and about 3 gig of disc that is currently working with 30% free space. I have 55 users on line at any given time with light batch processing during the day and heavy at night. We are currently on MPE V release 21 of platform 1P. I used PROBE from Strategic Systems to monitor the system performance and impact of KLA.
Before jumping full on into the review I want to cover some basics of the MPE scheduler to make sure we are all starting from the same starting point. For this purpose I am going to quote some from the KLA/Express manual. All processes start off at their ‘BASE’ priority. These priority numbers are set with the :TUNE command from MPE. For the first example, we will use the default priorities as established by HP. The “CS” queue, where on-line sessions are normally run, is set at a base priority of 152 and a limit priority of 200. Any process that starts a transaction in the “CS” queue will start at a priority of 152. As it uses CPU time, it’s priority is lowered (it will start dropping from 152 down to 200) until one of the following events occurs:
1. A terminal read is issued. If this is the case, the transaction is completed and the process returns to its “BASE” priority of 152 until a new transaction (hitting of the return or enter keys) is initiated.
2. The priority reached the priority “LIMIT”. Once this limit is reached, the process remains at this priority until a terminal read is issued or…
3. The process has a resource that a higher priority process requires. The higher priority process cannot execute until the lower priority process releases the resource. The lower priority process will temporarily have its priority raised until it releases the resource, then return to its lower priority number.
For batch jobs in the “DS” and “ES” queues, the same basic rules apply, except batch jobs normally do not issue any “terminal reads” and therefore usually go directly to their respective limits and remain there thrashing around with each other until the job completes.
Wouldn’t it be nice to control a critical process so it could force itself back up to base instead of banging around at the limit with the non-critical processes? Read on then and find out how you can with KLA/Express.
Features
There are basically two aspects to Express, the first is the program that allows you to define all your parameters and the second is the program that runs as a batch job in the background making the changes that you set up in the configuration program. It’s important to note at this point that you can maintain different configuration files and submit them to the background process anytime you want. This would of course allow you to keep radically different setups for different scenarios ready to go at any moment.
The first thing you would do with the program is to set up your Global Parameters, this section takes any valid MPE command that you want executed whenever this parameter file is submitted. This is usually a good place to put your TUNE commands, or even some of the stuff that is in your SYSSTART
file.
Your next step is to set up your customized queues for interactive and batch process’s. There are four different options for each of these sections and since they are the same for both, I will only cover them once.
On Line Response/Batch Throughput – These are the sections that you will use most, this is where you would set up your pseudo-queues. Here is an example of some of the configurations I used for On Line:
add 1 EXECSYS2.EXEC.SFD;3;154;I
add 2 FYIMAIL.PUB.SMGA;2;160;I
bypass 3 SPOOK.PUB.SYS
add 4 @.@.@;1;LIMIT;I
>/pre>
Ok, so what are we doing here; in the first line I am telling express to set up a pseudo limit of 154 for my menu program (EXECSYS2.EXEC.SFD) and as soon as a process drops to the limit immediately (I) return it to the base (3). In the second line I am setting a pseudo limit of 160 for my electronic mail system but instead of raising it to base when I reach pseudo limit, I want to only raise it to 2/3 base (2). I could also specify to raise 1/3 of base (0) or to leave at limit (0). The third line tells Express to ignore anything that is happening with SPOOK and our fourth line is a catch all so that everything else will be boosted to 1/3 base as soon as it hits the TUNE level for LIMIT for the CS queue, since we are working with on line process's here.
The syntax and philosophy behind Batch Throughput is identical, the actual parameters for these are described below;
3 3 = (raise to base)
sname,user.acct,group 2 2 = (raise to 2/3 base)
function seq pgmname.group.account[;1;nnn;I] 1 = (raise to 1/3 base)
ldev 0 = (leave at limit)
nnn = Pseudo Limit
I = Immediate
Functions = add,bypass,clear,del,help,modify,redo,refresh,save,submit
As you can see this allows you to control by program name, but by sign on and device number as well.
Our next option is the Modify Queue; this allows you to force a process into a different queue than it would normally execute. For example, you don't mind batch COBOL compiles, but the on lines stuff is strictly verbotten. So to 'punish' the online compile so it doesn't take everyone else's CPU time away you could add an entry like;
add 1 COBOLII.PUB.SYS;DS;;p
This tells Express to put the cobol program in the DS queue permanently for the length of this execution. Say however that you let people use QUERY on line for keyed lookups, but don't want them doing a long serial read, if they do you want to put it in the DS queue. You could then make an entry such as;
add 1 QUERY.PUB.SYS;DS;190;t
This tells Express to put Query into the DS queue as soon as it's limit is greater than 190, but only temporarily, as soon as the transaction is finished it will go back to the CS queue. Of course you can also use this to boost a process as well. Once again the logic between batch and online is the same, the format of the modify queue command follows;
sname,user.acct,group p p/t = Perm/Temp
func seq pgmname.group.account[;queue;nnn;t] queue = CS,DS or ES
ldev (default = DS)
nnn = Pseudo Limit
(default=LIMIT)
The next section is Abort, this section allows you define a process that is to be aborted if it exceeds the limits specified. These limits are either elapsed minutes or number of CPU seconds utilized. You can specify processes by logon, program or by ldev. Personally I didn't need to use this in production yet, but I did try it to test it and it worked fine.
The monitor section works like the abort section except that instead of aborting a process that exceeds your defined limits, it will notify the users defined in section 22 (which I am not going to cover) of the process. This gives you a more immediate feel of what is happening on your system as opposed to going through the reports after the fact.
This gets us to the Job Scheduler section. Strictly speaking this isn't a job scheduler, but what it does do is allow you to define multiple job queues which is also very handy. Briefly, what you can do is set a system job limit of say 10, this means that you can never have more than 10 jobs running at a time. Now make a job queue for G/L and specify that it has a job limit of 2, next make one for payroll and specify a job limit of 1. Finally define a job queue for A/R summary jobs of 5. Now what will happen if you stream 4 G/L jobs, 2 payroll jobs and 7 A/R summary jobs? Two of the G/L jobs will sign on, one of the payroll jobs and 5 of the A/R summary jobs, this still leaves room for 2 more jobs, but they would have to part of a different job queue.
The Job Scheduler is a handy tool to include in the software, but I doubt you will buy Express because of it. There are a few general purpose sections that deal with systems as well. First is to monitor for replies; how often has a reply scrolled off of your console to go unnoticed for god knows how long? Well by using this feature you can configure as many users as you want to be notified of replies. You can configure the rate that it is to keep telling you about the reply under the Modify Scan section.
There is a section to control disk caching based on the number of read hits, write hits and number of i/o's. You can specify it on a drive by drive basis which is better than the cache control you get from MPE. Personally I use a program I got from some HP rep years ago called DCOCOM that does dynamic cache control and it works great.
Last but certainly not least is the Show Cpu Utilization section. This is basically a poor mans Glance or Probe. It is a lot better than Tuner and is easier to understand than Surveyor. I think it is nice to throw in a CPU performance monitoring tool for free with the software. There are also a group of commands that is kind of a complimentary product called KLA/Commands. There is a lot of overlap here with MPEX, but they do have some pretty swell command to let you look at what is hitting the dispatcher at the moment and what priority it is at. Another one to modify the queue that a process is executing in to a different priority, and a whole bunch of others.
Usability (also installation)
The error checking in the software is very good, I wasn't able to do anything that was 'illeagle' for it. The only real mistakes you could make here is by misunderstanding a function and adding a valid entry that you didn't really want to have. Keep in mind this program is like nuclear power, it can do a lot of harm or good depending on how you use it.
The installation is the standard restore a file and stream a job type of thing that almost everybody use's. However the software is locked out until you talk to one of Unison's support people and have it unlocked. I personally don't like that kind of demo installation, but that's me.
Reliability
I didn't have any problems with the software at all, it didn't crash my system and it certainly would have the power to do it. It does run with privileged mode and I imagine they are getting into system tables, but I never had a dead lock or crash or mangled data. The software is written in COBOL so it gives all us aspiring COBOL system programmers hope.
Performance
The only impact Express has on performance is to improve it. I have to typically single thread my jobs, but by using Express I was able to let more go simultaneously without adversely impacting my online response, and getting the jobs done faster at the same time. The reports that Express can provide ,if you are using their logging, are very informative and can be used to fine tune the product even more by pointing out your trouble spots. The product doesn't take much disk space.
Supportability (including Doc)
The support from Unison for Express is good, they managed to hire one of the people from KLA during the buy out, so they have at least one Express guru on staff. Their support person called me to check up to make sure the stuff
we had tried had worked ok and even dialed in to check my log reports to see
what other fine tuning might be called for. The manual's included with Express do a good job of explaining a difficult to understand topic, I would say the only spot they are week on is in explaining the job scheduler portion. They are the original manuals that KLA was using with the product, I understand that the new release of Express that KLA was planning before the buy out is still on the way and with it new documentation. It will be interesting to see how Express is brought into the Unison software fold.
Summary
Express is one of about 4 products that I feel is a real necessity to any MIS shop, the others are MPEX and NBSPOOL. I suppose I might upset some software vendors with that comment, but for me at least, it's true. If you are planning a CPU upgrade because of poor response time, or are just experiencing poor response time, you owe it to yourself to get a demo of this product. I'm supposed to come up with at least a couple of negatives about a product, but I don't know if I can with this one. The on line help is actually the manual that comes with the software, and is context sensitive.
At-a-Glance box
KLA/Express version 5.00.E
Unison Software
675 Almanor Ave.
Sunnyvale CA 94086
408-245-3000
FAX 408-245-1412
Call, write or FAX for information and/or demo
$???? per copy which includes ?? support and one 41 page manual
Good Points
Does wonderful things for response time
easy to use
little maintenance once installed
Bad Points
They don't restore or fully reset the function keys when the program exits, an older version use to restore the function keys, I don't know why they stopped doing in.
Installs both CM and NM versions which is wasteful of disk space.